A data communications network generally includes a group of devices, for instance, computers, repeaters, bridges, routers, etc., situated at network nodes and a collection of communication channels for interconnecting the various nodes. Hardware and software associated with the network and particularly the devices permit the devices to exchange data electronically via the communication channels.
In order to keep track of and manage the various devices situated on a network, various management protocols have been developed. Examples of these management protocols include the simple network management protocol (SNMP), the common management information protocol (CMIP) standardized by the International Organization for Standardization (ISO), proprietary protocols that can be found in proprietary network environments, such as SNA.TM. from IBM Corp. and NETWARE.TM. (NW) from Novell Corp., and remote procedure call protocols (RPC), such as the distributed computing environment protocol (DCE-RPC) that was developed by the Open Software Foundation. The use of the foregoing protocols has become extensive in the industry, and numerous vendors now manufacture many types of network devices which can employ these protocols.
Many management software packages ("management platforms") are presently available for implementing "management stations" on a network. Examples of commercially available management software packages include "OPENVIEW".TM. (or "HP OPENVIEW".TM.) from the Hewlett-Packard Company, which is the assignee herein, "NETVIEW".TM. from IBM Corp., "SPECTRUM".TM. from Cabletron Systems, Inc., "NETLABS MANAGER".TM. from NetLabs, Inc., and "SUNNET MANAGER".TM. from Sunconnect Inc. The nodes on the network and their interconnections, oftentimes referred to as the network "topology," are best displayed in a graphical format, and most, if not all, of the available management software packages provide for this feature.
Typically, with these packages, a network can be viewed from different vantage points, depending on the scope of the view that is desired. For example, one view of the network could be a very wide encompassing view of all nodes on the entire network. A second view could be a view of those portions of a network within a local range, for example, within a particular site or building. A third view of a network, often called a segment, could be a view of nodes attached to a particular local area network (LAN) cable.
Hewlett-Packard's very successful "OPENVIEW".TM. has been the subject of several patents, including for instance, U.S. Pat. No. 5,185,860 issued to J. C. Wu on Feb. 9, 1993, and U.S. Pat. No. 5,276,789 issued to Besaw et al., on Jan. 4, 1994. U.S. Pat. No. 5,185,860 describes an automatic discovery system for a management system for determining the network devices and interconnections of a network, or the topology. U.S. Pat. No. 5,276,789 describes a graphic display system for a management station for graphically displaying the topology of a network and provides for various views (including, internet, segment, and node views) that can be requested by a user.
Although the presently available management stations are meritorious to an extent, the art of management stations is still in a state of infancy, and the performance of current management stations can still be enhanced and optimized. A specific area where optimization is envisioned involves the sharing of information derived from events among applications that are associated with the management stations. Herein, an "event" is a notification emitted by any element in the managed environment to indicate a change in state. Events are typically asynchronous relative to the management station. Moreover, there already exist numerous event forwarding and distribution mechanisms, but each is highly tuned to a particular environment or protocol domain. This predicament causes several problems.
First, many applications require access to notifications for more than one of the protocol domains making up the managed environment. However, their implementation is currently complicated due to the number and variety of protocols and interfaces required. Application access to event data should not be burdened by a required understanding of the detailed syntax and semantics of environment-specific protocols, representations of, and interfaces to, the event data.
Second, there is no single, common mechanism for gathering notifications from multiple domains. In the context of this document, a "notification" is any message that is emitted asynchronously with respect to a receiver and in a logically non-directed fashion. In some cases, specific modules have been created to map notifications from one mechanism to another, but this results in an "n by m" problem and often distorts the information because of the target's environment-specific, often nonapplicable elements. In some cases, information from an original notification is lost altogether, because there is no semantically comparable structure in the target.
Third, applications do not have a common integration mechanism for exchanging asynchronous messages among the applications.
Fourth, there is little in the way of shared semantics between applications to allow the creation of generic functions. Specifically, there is no current way to implement a common event management console, a common filtering mechanism, or common tools that can be applied to all variants of event data.
Thus, a heretofore unaddressed need exists in the industry for a system and method for enhancing operation of a management station on a network by integrating and correlating information from different protocols.